home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1131 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.3 KB
  1. Subject: Re: user-written interrupt handlers 
  2. Date: Thu, 03 Mar 1994 19:55:57 -0800
  3. From: Howard Chu <hyc@hanauma.jpl.nasa.gov>
  4.  
  5.  
  6.   Signal handlers aren't good replacements for interrupts; they take too
  7.   much time to be serviced -- maybe a tenth of a second, versus a few
  8.   microseconds for an interrupt handler. It would be unusable, for
  9.   instance, for the serial interrupts, while it would be quite appropriate
  10.   for "Monochrome Detect", say.
  11.  
  12. Well, since my only purpose here was to drive my interrupt-driven sound
  13. routines on the Falcon, that was just fine anyway. (Using the monochrome
  14. detect interrupt, fancy that.)
  15.   
  16.   On the other hand, it should be _possible_ for an interrupt handler to
  17.   raise a signal; for instance, in the case of a SLIP handler, we'd like
  18.   to receive a signal (or whatever) when a datagram has been completely
  19.   received, not at every received character...
  20.   
  21.   But I don't know if it is safe to call Pkill (via the kernel) in an
  22.   interrupt handler.
  23.  
  24. That's exactly what my psigintr code does, it allows an interrupt handler to
  25. raise a signal. It does it by calling post_sig directly, which is the actual
  26. kernel routine that Pkill calls to raise the signal in the target process. It
  27. also avoids calling check_sigs, so no problems there either. I would guess this
  28. would also make an ideal approach for a SLIP or PPP handler...
  29.